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MasterTask:  The  Durra  Task  Emulator 

Abstract.  Durra  Is  a  language  designed  to  suppor  the  construction  of  distributed 
applications  using  concurrent,  coarse-grain  tasks  running  on  networks  of  hetero¬ 
geneous  processors.  An  application  written  in  Durra  describes  the  tasks  to  be 
instantiated  and  executed  as  concurrent  processes,  the  types  of  data  to  be  ex¬ 
changed  by  the  processes,  and  the  intermediate  queues  required  to  store  the  data 
as  they  move  from  producer  to  consumer  processes. 

The  tasks  and  types  available  to  an  application  developer  are  described  by  a  col¬ 
lection  of  Durra  task  descriptions  and  type  declarations  stored  in  a  library.  One  of 
the  components  of  a  task  description  is  a  specification  of  the  external  timing  be¬ 
havior  of  the  task.  It  describes  the  sequence  of  incut  and  output  port  operations 
and  the  amount  of  processing  time  spent  between  port  operations. 

This  report  describes  MasterTask,  a  program  that  c  an  emulate  any  task  in  an  ap¬ 
plication  by  interpreting  the  timing  expression  desc  ibing  the  behavior  of  the  task, 
performing  the  input  and  output  port  operations  in  the  proper  sequence  and  at  the 
proper  time. 

MasterTask  is  useful  to  both  application  developers  and  task  developers.  Appli¬ 
cation  developers  can  build  early  prototypes  of  ar  application  by  using  Master- 
Task  as  a  substitute  for  task  implementations  that  have  yet  to  be  written.  Task 
developers  can  experiment  with  and  evaluate  proposed  changes  in  task  behavior 
or  performance  by  rewriting  and  reinterpreting  the  corresponding  timing  expres¬ 
sion. 


1.  Introduction  to  Durra 

Durra  [1 , 2]  is  a  language  designed  to  support  the  con  Jtruction  of  distributed  applications 
using  concurrent,  coarse-grain  tasks  running  on  network:;  of  heterogeneous  processors.  An 
application  written  in  Durra  selects  and  reuses  task  descriptions  and  type  declarations 
stored  in  a  library.  The  application  describes  the  tasks  to  be  instantiated  and  executed  as 
concurrent  processes,  the  types  of  data  to  be  exchanged  by  the  processes,  and  the  interme¬ 
diate  queues  required  to  store  the  data  as  they  move  fron  producer  to  consumer  processes. 

Because  tasks  are  the  primary  building  blocks,  we  refer  to  Durra  as  a  task-level  description 
language.  We  use  the  term  “description  language"  rather  than  "programming  language"  to 
emphasize  that  a  Durra  application  is  not  translated  Into  object  code  In  some  kind  of  ex¬ 
ecutable  (conventional)  “machine  language.”  Instead,  a  Durra  application  is  a  description  of 
the  structure  and  behavior  of  a  logical  machine  to  be  synthesized  Into  resource  allocation 
and  scheduling  directives,  which  are  then  interpreted  by  a  combination  of  software, 
firmware,  and  hardware  in  each  of  the  processors  and  buffers  of  a  heterogeneous  machine. 
This  is  the  translation  process  depicted  in  Figure  1-1. 

We  see  three  distinct  phases  in  the  process  of  develop  ng  an  application  using  Durra:  the 
creation  of  a  library  of  tasks,  the  creation  of  an  application  using  library  tasks,  and  the  ex¬ 
ecution  of  the  application. 
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Status  and  Task  requests 
Get/Put  data 
Test  port 
Terminate  task 


—/  I  Scheduler 

Schedule 

Conectivity 
Task  names 
Transformations 


]  => 


Messages 
Start  task 
Allocate  queue 
Shutdown 


Figure  1-1 :  Compilation  of  an  Application  Description 


During  the  first  phase,  the  developer  writes  descriptions  of  the  components  tasks.  These 
task  descriptions  specify  the  properties  of  a  task  implementation  (a  program).  For  a  given 
task,  there  may  be  many  implementations,  differing  in  programming  language  (e.g.,  C  or 
assembly  language),  processor  type  (e.g.,  Motorola  68020  or  IBM  1401),  performance  char¬ 
acteristics,  or  other  attributes.  For  each  implementation  of  a  task,  a  description  must  be 
written  in  Durra,  compiled,  and  entered  in  the  library. 

A  task  description  includes  specifications  of  a  task  implementation  timing  behavior  and  func¬ 
tionality,  the  types  of  data  it  produces  or  consumes,  the  ports  it  uses  to  communicate  with 
other  tasks,  and  other  miscellaneous  attributes  of  the  implementation. 

During  the  second  phase,  the  user  writes  an  application  description.  Syntactically,  an  appli¬ 
cation  description  is  a  single  task  description  and  could  be  stored  in  the  library  as  a  new 
task.  This  allows  writing  of  hierarchical  application  descriptions.  When  the  application  de¬ 
scription  is  compiled,  the  compiler  generates  a  set  of  resource  allocation  and  scheduling 
commands  or  instructions  to  be  interpreted  by  the  scheduler. 

During  the  last  phase,  the  scheduler  loads  the  task  implementations  (i.e.,  programs  cor¬ 
responding  to  the  component  tasks)  to  the  processors  and  issues  the  appropriate  com¬ 
mands  to  execute  the  programs. 

Task  descriptions  are  the  building  blocks  for  applications.  Task  descriptions  include  the  fol¬ 
lowing  information  (see  Figure  1-2):  (1)  its  interface  to  other  tasks  (ports)  and  to  the 
scheduler  (signals);  (2)  its  attributes;  (3)  its  functional  and  timing  behavior;  and  (4)  its  in¬ 
ternal  structure,  thereby  allowing  for  hierarchical  task  descriptions.  For  the  purposes  of  this 
report,  the  relevant  components  of  a  task  description  are  the  behavioral  specifications. 
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task  task-name 
ports 


—  Used  for  communication  between  a  process  and  a  queue 

port-declarations 


signals 

—  Used  for  communication  between  a  process  and  the  scheduler 

signal-declarations 

attributes 

—  Used  to  specify  miscellaneous  properties  of  the  task 

attribute-value-pairs 

behavior 

—  A  description  of  the  functional  and  timing  behavior  of  the  task 
requires  predicate 
ensures  predicate 
timing  timing  expression 
structure 

—  A  graph  describing  the  internal  structure  of  the  task 

process-declarations 

—  Declaration  of  instances  of  internal  subtasks 


bind-declarations 

—  Mapping  of  internal  process  ports  to  this  task' s  ports 

queue-declarations 

—  Means  of  communication  between  internal  processes 


reconfiguration-statements 
end  task-name 


—  Dynamic  modifications  to  the  structure 


Figure  1-2:  A  Template  for  Tasl<  Descriptions 
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2.  Durra  Behavioral  Specifications 


The  behavioral  information  part  of  a  task  description  specifies  functional  and  timing 
properties  of  the  task.  It  consists  of  a  functional  information  part  and  a  timing  expression. 
The  functional  information  part  consists  of  a  pre-condilion  predicate  on  what  is  required  to 
be  true  of  the  data  coming  through  the  input  ports  and  a  post-condition  predicate  on  what  is 
guaranteed  to  be  true  of  the  data  going  out  through  the  output  ports.  The  timing  expression 
describes  the  behavior  of  the  task  in  terms  of  the  operations  it  performs  on  its  input  and 
output  ports. 

Timing  expressions  are  the  critical  piece  of  information  used  by  MasterTask.  The  syntax 
and  semantics  of  timing  expressions  are  described  below.  For  additional  information  about 
the  syntax  and  semantics  of  the  functional  information  part,  see  the  Durra  reference  manual 
[1]. 


2.1.  Timing  Expressions  This  section  Is  reproduced  from  [1]. 

Processes  remove  data  from  their  input  queues  and  sto'e  data  in  their  output  queues  follow¬ 
ing  a  task-specific  pattern  provided  by  a  timing  expression.  A  timing  expression  describes 
the  behavior  of  the  task  in  terms  of  the  operations  it  performs  on  its  input  and  output  ports; 
this  is  the  behavior  of  the  task  seen  from  the  outside. 

2.1.1.  Time  Literals 


Syntax: 

TixneLiteral 

Seconds 

TimeBase 


IndeterminateTime 


Seconds  {  TimeBase  }  , 
IndeterminateTime 

IntegerValue  , 
RealValue 


'  'DTIME'  ' 
'  'ATIME'  ' 
'  'PTIME'  ' 


—  Time  since  start  of  day 
—  Time  since*  the  start  of  the  application 
—  Time  nince  the  start  of  the  process 


\  t 


Examples: 

3615.5  atlme  —  An  application  relative  time:  1  hour  and  15.5  seconds 

—  after  the  start  of  the  application. 

2.25  — •  Two  and  a  quarter  seconds  relative  to  some  previous  event 

*  — -  A i  indeterminate  point  in  time. 
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Meaning: 

Time  values  are  used  to  specify  points  in  time.  These  can  be  either  (1 )  absolute,  in  which 
case  they  must  be  followed  by  the  name  of  a  time  base  (the  start  of  the  day,  the  application, 
or  the  process);  or  (2)  relative  to  some  prior  event  in  a  timing  expression,  in  which  case  a 
time  base  is  not  allowed.  All  time  values  are  measured  in  seconds. 


2.1.2.  Event  Expressions  and  Time  Windows 


Syntax: 

Event 


TimeWindow 


GlobalPortName  {  ' ' . 9  '  QueueOperation  }  , 
' 'DELAY' '  TimeWindow 

' ' [ '  9  Time Value  ' ' , 9  '  TimeValue  ' ' ] ' ' 


QueueOperation  : :=  ''ENQUEUE''  , 

'  'DEQUEUE' ' 


Examples: 


ini  —  An 

ini . dequeue 
delay [10,  15] 
delay!*,  10] 
delay [10,  *] 


operation  (Dequeue,  by  default)  on  the  queue  feeding  ini. 

—  The  same  operation  as  above. 
—  A  delay  interval  lasting  between  10  and  15  seconds. 

—  A  delay  interval  taking  at  most  10  seconds. 
—  A  delay  interval  taking  at  least  10  seconds. 


Meaning: 

Queue  operations  performed  by  the  processes  constitute  the  basic  events  of  an  application 
description.  An  event  expression  represents  a  queue  operation  on  a  queue  attached  to  a 
specific  port,  taking  a  variable  amount  of  time  to  complete.  A  pseudo-operation,  “delay,”  is 
used  to  represent  the  time  consumed  by  the  process  between  (real)  queue  operations. 

The  name  of  the  queue  operation  is  optional.  If  the  name  is  not  given,  a  default  queue 
operation  is  assumed:  “dequeue”  for  input  ports,  “enqueue”  for  output  ports. 

Intervals  of  time  between  queue  operations  are  denoted  by  a  “delay”  operation  whose  time 
window  describes  the  minimum  and  maximum  time  consumed  by  the  process  in  between 
queue  operations. 

2.1.3.  Timing  Expressions 

Syntax: 

TlmingExpreasion  :  {  ''LOOP''  )  SequentialEvent 

SequentialEvent  : :=  ParallelEvent_Listia€  B 
ParallelEvent  :  :=  BasicEvent_Listdoubl#  v.rtlcal  bar 
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BasicEvent  : : =  Event  , 

{  Guard  ''«=>"  }  qi[(]  ! Sequent ialEvent  ")") 

Guard  : :=  '  'REPEAT' '  ZntegerValue  , 

'  'BEFORE' '  TimeValue  , 

'  'AFTER' '  TimeValue  , 

' 'DURING' '  TimeWindow  , 

' 'WHEN' '  Expression 

Examples: 

ini  |  |  in2  —  Two  parallel  input  operations,  starting  simultaneously. 

ini  delay [10 ,15]  outl  —  Three  sequential  operations. 

repeat  5  =>  (ini  delay [10,15]  outl) 

—  Same  as  above  but  an  a  cycle  repeated  five  times . 

before  64800  DTIME  =>(...) 

—  A  sequence  constrained  to  start  before  6  pm. 
(18  hours  or  18*3600  seconds  after  the  start  of  the  day) 

after  64800  DTIME  =>(...) 

—  A  sequence  constrained  to  start  after  6  pm. 

during  [64800  DTIME,  7200]  =>(...) 

—  A  sequence  constrained  t;o  start  between  6  pm  and  8  pm 

T _ is  2  hours  counted  from  the  start  of  the  time  window. 

max 

when  (Current_Size (ini)  >  0)  and  (Current  Size(in2)  >  0)  => 

( (ini  | |  in2)  outl) ; 

—  A  sequence  that  starts  after  both  input  queues  have  data. 

loop  When  (Current_Size(inl)  >  0)  and  (Cuzrent_Size  (in2)  >  0)  => 

((ini  M  in2)  outl); 
—  The  same  sequence  as  abcve  but  repeated  indefinitely. 

Meaning: 

A  timing  expression  is  a  regular  expression  describing  the  patterns  of  execution  of  opera¬ 
tions  on  the  input  and  output  ports  of  a  task.  The  keyword  loop  can  be  used  to  indicate  that 
the  pattern  of  operations  is  repeated  indefinitely. 

A  timing  expression  is  a  sequence  of  parallel  event  expressions.  Each  parallel  event  ex¬ 
pression  consists  of  one  or  more  event  expressions  separated  by  the  symbol  ||  to  indicate 
that  their  executions  overlap.  Since  the  expressions  might  take  different  amounts  of  time  to 
complete,  nothing  can  be  said  about  their  completion,  other  than  a  parallel  event  expression 
terminates  when  the  last  event  terminates. 

A  basic  event  expression  is  either  a  queue  operation  (including  “delay”)  or  a  timing  expres¬ 
sion  enclosed  in  parentheses.  The  latter  form  also  allows  for  the  specification  of  a  guard,  an 
expression  specifying  the  conditions  under  which  a  sequence  of  operations  is  allowed  to 
start  or  repeat  its  execution. 


—  Absolute  time 
—  Absolute  time 

—  Tmin  *-s  Absolute  time 

—  A  Boolean  expression 
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Guard  Description 

repeat  This  guard  indicates  repetitions  of  a  timing  expression.  The  number  of 

repetitions  is  a  non-negative  integer  value. 

before  This  guard  is  followed  by  an  absolute  time  value  representing  the  latest 

start  time  allowed.  The  task  is  terminated  if  a  deadline  has  elapsed. 

after  This  guard  is  followed  by  an  absolute  time  value  representing  the  ear¬ 

liest  start  time  allowed.  If  necessary,  the  sequence  is  blocked  until  the 
deadline. 

during  This  guard  is  followed  by  a  time  window  during  which  the  sequence  is 

allowed  to  start.  The  first  value  is  the  earliest  start  time  allowed  and 
must  be  an  absolute  time  value;  the  second  value  is  the  latest  start  time 
allowed  and  can  be  an  absolute  time  value  or  a  time  value  relative  to 
the  former. 

when  This  guard  describes  what  is  required  to  be  true  of  the  state  of  the  sys¬ 

tem  (i.e.,  time  and  queues;  see  Section  2.2)  before  the  sequence  is  al¬ 
lowed  to  start.  It  is  a  pre-condition  for  starting  the  sequence. 

2.1.4.  Restrictions  on  Time  Values  and  Time  Windows 

Although  the  syntax  allows  both  absolute  and  relative  time  values  to  appear  in  either  of  the 

two  boundaries  in  a  time  window,  not  all  of  the  possible  combinations  make  sense: 

1.  In  the  time  window  attached  to  “delay"  operation,  the  time  values  must  be  rel¬ 
ative  (i.e.,  no  time  basis  allowed)  and  are  interpreted  relative  to  the  start  of  the 
operation. 

2.  In  the  time  window  of  a  during  guard,  the  first  time  value  (Tmin)  must  be  abso¬ 
lute.  The  second  time  value  (Tmax)  can  be  absolute  or  relative.  In  the  latter 
case,  the  time  value  is  relative  to  Tmin. 


2.2.  Predef  ined  Functions  This  section  Is  reproduced  from  [1J. 

A  small  number  of  functions  are  predefined  in  the  language.  These  functions  are  used  to 
obtain  the  current  time  in  the  various  time  bases,  to  perform  computations  with  time  values, 
and  to  obtain  the  number  of  elements  stored  in  a  queue.  These  functions,  together  with 
time  and  numeric  literals,  constitute  the  terms  used  to  build  expressions  in  timing  guards 
and  reconfiguration  conditions. 

Syntax: 

FunctionCall  : : =  Funct  ionName  {  FunctlonParameters  } 

Funct  ionName  : :=  ' ' CURRENT_DT IME ' '  , 

'  '  CURRENT_AT  I  ME '  '  , 

' ' CURRENT_P  TIME ' '  , 

'  'MINUSJTIME'  '  , 

'  'PLUSJTIME'  '  , 

' 'CURRENT  SIZE' ' 
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FunctionParameters  :  ' '  ('  '  DurraValue_LiiitcoxnmA 

—  The  type  and  number  of  parrjneters  is  function  dependent. 


Examples: 

Plus_Time  (Current_DTime,  9000) 

—  2.5  hourj;  from  the  current  time  of  day 
Current_Size (Master_Process .Data_Port) 

—  the  t ize  of  a  queue  feeding  a  port 


Meaning: 

The  following  functions  are  predefined  in  the  language:  "currentjdtime,”  “current_atime,’’ 
‘‘current_ptime,"  ‘'minus_time,”  “plus_time,”  and  “currert_size." 

The  functions  with  names  like  “Current_?Time”  return  the  current  time  as  a  number  of 
seconds  relative  to  the  appropriate  time  base. 

The  function  call  “MinusJTimeCTimeValue^TimeValueg)”  returns  the  time  value  obtained 
by  subtracting  TimeValue2  from  TimeValue^  The  following  cases  are  allowed: 

1.  If  both  parameters  are  absolute  times,  the  result  is  a  relative  time,  i.e.,  a  dura¬ 
tion  (in  seconds). 

2.  If  TimeValue1  is  an  absolute  time  and  TimeValue2  is  a  relative  time,  the  result 
is  an  absolute  time  with  the  same  time  base  as  TimeValue^ 

3.  If  both  parameters  are  relative  times,  the  result  is  a  relative  time. 

The  function  call  ,,Plus_Time(TimeValue1  ,TimeValue2)"  returns  the  time  value  obtained  by 
adding  TimeValue2  to  TimeValue,.  The  following  cases  are  allowed: 

1.  If  one  parameter  is  an  absolute  time  and  the  otheir  parameter  is  a  relative  time, 
the  result  is  an  absolute  time  in  the  same  time  base. 

2.  If  both  parameters  are  relative  times,  the  result  s  a  relative  time,  i.e.,  a  dura¬ 
tion. 

The  function  call  ,,Current_Size(GlobalPortName)"  returns  the  current  number  of  elements 
stored  in  the  queue  associated  with  a  given  port. 

Calls  to  these  functions  can  appear  anywhere  a  value  c  f  the  same  kind  as  the  return  value 
can  appear.  That  is,  a  call  to  a  function  returning  an  integer,  a  real,  a  string,  or  a  time  value 
can  appear  instead  of  an  integer,  a  real,  a  string,  or  a  tirre  value,  respectively. 
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3.  Durra  Runtime  Environment 


To  understand  the  operation  of  MasterTask,  it  is  necessary  to  understand  the  components 
of  the  Durra  runtime  environment.  MasterTask  operates  like  any  other  task  implementation. 
It  does  not  receive  special  treatment  by  the  runtime  env  ronment  and,  in  fact,  the  scheduler 
and  servers  have  no  built-in  knowledge  of  MasterT ask.  This  section  provides  the  summary 
of  the  runtime  environment  necessary  to  understand  how  task  implementations  are  invoked 
and  how  they  can  receive  information  contained  in  the  task  description.  How  MasterTask 
uses  this  information  is  the  subject  of  Section  4.4.  For  further  details  about  the  runtime 
environment,  see  [3]. 


Figure  3-1 :  The  Durra  Runtime  E-nvironment 


There  are  three  active  components  in  the  Durra  runtime  environment:  the  application  tasks, 
the  Durra  server,  and  the  Durra  scheduler.  Figure  3-1  shows  the  relationship  between  these 
components. 
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After  compiling  the  type  declarations,  the  component  task  descriptions,  and  the  application 
description,  as  described  previously,  the  application  can  be  executed  by  performing  the  fol¬ 
lowing  operations: 

1.  The  component  task  implementations  must  be  loaded  in  a  special  directory  in 
the  appropriate  processors.  The  directory  name  is  known  to  the  Durra  servers 
and  scheduler.  Since  MasterTask  is  playing  the  role  of  a  task  implementation, 
it  too  must  be  stored  in  this  special  directory. 

2.  An  instance  of  the  Durra  server  must  be  started  in  each  processor. 

3.  The  scheduler  must  be  started  in  one  of  the  processors.  The  scheduler 
receives  as  an  argument  the  name  of  the  file  containing  the  scheduler  pro¬ 
gram  generated  by  the  compilation  of  the  application  description.  This  step 
initiates  the  execution  of  the  application. 

The  scheduler  is  the  part  of  the  Durra  runtime  system  responsible  for  starting  the  tasks, 
establishing  communication  links,  and  monitoring  the  execution  of  the  application.  In  addi¬ 
tion,  the  scheduler  implements  the  predefined  tasks  (broadcast,  merge,  and  deal)  de¬ 
scribed  in  [1].  The  scheduler  operates  by  reading  a  file  containing  the  instructions  gener¬ 
ated  by  the  Durra  compiler.  For  the  purposes  of  this  reports,  the  two  relevant  instructions 
are  taskjoad  and  source. 

The  taskjoad  instruction  takes  three  parameters:  1)  the  task  name,  2)  a  processor  to  run  it 
on  (either  a  specific  processor  or  a  class  of  processors),  and  3)  the  name  of  the  executable 
file. 


(task_load  MAIN. PC  VAX  "sink_task2") 

The  source  instruction  takes  two  parameters:  1)  a  task  name,  and  2)  the  value  of  the 
"source"  attribute  specified  in  the  task  description,  if  any. 

(source  MAIN. DISPLAY  "display. durra. TREE") 

If  the  source  attribute  is  not  specified  in  the  task  description,  the  parameter  is  the  name  of 
the  syntax  tree  produced  by  the  Durra  compiler  (see  [3]  for  file-naming  conventions).  This 
information  might  be  used  by  the  task  implementation  to  examine  its  own  Durra  description. 
This  information  will  be  passed  to  the  indicated  application  task  at  startup.  The  significance 
of  the  “implementation,”  “source,”  and  "processor"  attributes  will  become  clear  in  Section 
4.4. 
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4.  MasterTask  Implementation  Overview 

As  described  in  Section  2.1,  a  Durra  timing  expression  can  contain  concurrent  events  as 
well  as  loops  and  guards  that  block  execution  until  some  condition  is  met  (e.g.,  some 
amount  of  time  has  elapsed  since  the  start  of  the  application,  an  input  queue  has  a  given 
number  of  data  elements).  In  this  section  we  describe  the  use  of  Ada  tasking  features  to 
implement  concurrent  events.  In  this  description,  wWhenever  there  is  the  possibility  of  con¬ 
fusion,  we  will  use  the  term  “Ada  task”  to  distinguish  it  from  a  “Durra  task.”  Otherwise  the 
context  should  make  it  clear  which  type  of  task  is  implied. 

When  MasterTask  starts,  it  reads  the  Durra  syntax  tree  of  the  task  it  wants  to  emulate,  lo¬ 
cates  the  timing  expression,  and  builds  an  internal  data  structure,  isomorphic  to  the  original 
timing  expression  syntax  tree,  but  with  different  information  stored  in  the  nodes.  In  partic¬ 
ular,  each  node  in  the  internal  tree  contains  a  reference  to  a  task  object.  This  task  object  is 
responsible  for  performing  one  or  more  node-dependent  operations:  1)  execute  a  queue 
operation  (including  “delay”);  2)  evaluate  a  guard  expression  (including  "repeat”);  3)  direct 
the  execution  of  the  tasks  responsible  for  the  subtrees  rooted  at  this  node. 

Generally,  MasterTask  exhibits  the  same  behavior  as  £.  regular  Durra  task  implementation, 
issuing  the  same  calls  to  the  scheduler  (see  [3]  for  a  description  of  the  operations)  in  the 
following  order: 

1 .  Calls  the  Init  function  to  establish  communication  with  the  scheduler.  This  op¬ 
eration  is  invoked  by  MasterTask’s  main  program  during  the  initialization 
phase. 

2.  Calls  get_portid  for  each  of  the  task  ports  (these  are  the  ports  named  in  the 
timing  expression).  These  operations  are  invoked  while  building  the  internal 
structures. 

3.  Calls  send_port  and  get_port  as  necessary  to  send  and  receive  data.  In  be¬ 
tween  port  operations,  it  might  wait  for  varying  amounts  of  time,  as  indicated  in 
the  timing  expression.  These  operations  are  invoked  by  the  Ada  task  objects, 
operating  concurrently  as  they  interpret  their  assigned  nodes. 

4.  Calls  finish  to  break  communication  with  the  scheduler  when  it  completes  its 
job.  This  operation  is  invoked  by  MasterTask’s  main  program  after  the  Ada 
task  object  assigned  to  the  root  node  has  termin  ated  (and  by  implication,  all  of 
the  task  objects  are  terminated).  If  the  timing  expression  contains  a  never- 
ending  loop  or  a  guard  that  is  not  satisfied,  at  least  one  of  the  task  objects  will 
not  terminate  and  the  finish  operation  will  not  be  invoked.  In  this  case  Mas¬ 
terTask  must  be  terminated  by  the  scheduler. 

4.1.  The  Ada  Task  Type  Specification 

All  of  the  task  objects  assigned  to  the  nodes  are  instances  of  the  same  task  type: 

task  type  Master_Task_Teinplate  is 
entry  Start (e:  in  FSA_Node) ; 
entry  Stop; 

end  Master_Task_Template; 
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The  task  type  specification  indicates  that  the  task  objects  will  have  two  entry  points,  "Start" 
and  “Stop.”  All  coordination  of  activities  will  be  performed  by  calling  these  entries. 


4.2.  The  Ada  Task  Type  Body 

task  body  Master_Task_Template  is 
el ,  e2 :  FSA_Node ; 
begin 
loop 

accept  start (e:  in  FSA_Node)  do 

el  :=  e;  — |  remember  the  node  we  are  responsible  for 

end  start; 

case  el. kind  is  — |  perform  a  node -dependent  action 

when  FSA  Event  => 


when  FSA_Repeat  => 


when  FSA  Guard  => 


when  FSA  List  => 


end  case; 
accept  stop; 
end  loop; 

end  Master_Task_Template; 

The  body  of  the  task  type  implementation  consists  of  a  loop  containing  three  steps: 

1.  Perform  an  accept  "Start”  statement.  When  the  rendezvous  occurs,  the 
parent  task  (the  caller)  is  released  immediately  after  a  simple  assignment 
statement  is  executed  by  the  entry  proper. 

2.  Perform  some  node-dependent  action  (e.g.,  delay,  invoke  a  queue  operation, 
start  several  children  processes  in  parallel). 

3.  Perform  an  accept  "Stop”  statement.  The  entry  call  to  "Stop”  serves  as  a 
lock  to  the  parent  task.  The  parent  cannot  continue  until  the  child  task  arrives 
here,  i.e.,  until  it  has  completed  performing  the  node-dependent  action.  When 
the  rendezvous  occurs,  the  parent  task  (the  caller)  is  released  and  the  child 
task  loops  to  its  accept  “Start”  statement. 

The  node-dependent  actions  are  shown  in  an  abridged  fashion.  We  eliminated  all  details 
except  those  that  illustrate  the  synchronization  between  parent  and  children  tasks: 

when  FSA_Event  => 
do_operation(el) ; 

The  simplest  node-dependent  action  performs  a  delay  or  a  queue  input  or  output  operation. 
A  delay  operation  is  associated  with  a  time  window  that  specifies  a  minimum  and  maximum 
delay.  MasterTask  draws  a  random  number  from  a  uniform  distribution  between  these  two 
boundaries  and  uses  it  as  the  length  of  time  it  delays  its  operation  (this  is  implemented  with 
an  Ada  delay  statement). 
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Normally,  queue  input  and  output  operations  are  performed  by  issuing  the  send _port  and 
get_port  schedulers  call,  as  described  in  [3].  MasteTask  can  also  be  used  as  a  frees¬ 
tanding  program,  running  without  the  help  of  the  Durra  runtime  system  (see  Section  4.5).  In 
freestanding  mode,  queue  operations  are  emulated  by  using  a  default  delay  duration  (0.1 
second). 

when  FSA_Repeat  => 
for  i  in  1 . . el . count 
loop 

el .rezpression.node_task. staxt (el. rexpression) ; 
el . rexpression. node_task. stop; 
end  loop; 

A  node  that  implements  a  “repeat”  guard  invokes  its  child  task  a  number  of  times  “count.” 
The  parent  task  calls  the  "Start”  entry  and  blocks  until  the  child  task  gets  there.  Once  they 
are  both  synchronized,  the  parent  is  released  and  the  child  goes  on  to  execute  the  loop 
body.  The  parent  task  immediately  calls  the  “Stop”  en  :ry  and  blocks  until  the  child  task  gets 
there  (i.e.,  until  the  child  task  has  completed  one  iteration).  At  that  point  both  tasks  are 
released.  The  child  task  goes  back  to  the  head  of  *:he  outer  loop  to  the  accept  "Start" 
statement  and  waits  there  until  the  next  time  it  is  called  upon  to  evaluate  its  subtree.  The 
parent  task  either  loops  again,  or  terminates  the  loop  and  goes  to  its  accept  "Stop”  state¬ 
ment. 


when  FSA_Guard  => 

while  not  DojGuard(el) 
loop 

delay  Delay_Between_Retries; 
end  loop; 

el .  expression . node_task .  start  (€;1 .  expression)  ; 
el . expression . node_task . stop; 

A  node  that  implements  a  guard  (other  than  a  “repeat”  guard)  loops  evaluating  the  guard 
expression  until  it  is  satisfied.  When  that  occurs,  the  node  invokes  its  child  task  to  perform 
the  guarded  timing  expression.  The  parent  first  calls  the  “Start"  entry,  thus  triggering  the 
child,  and  then  calls  the  "Stop"  entry  and  blocks  until  the  child  task  gets  there.  To  avoid 
wasting  resources  and  to  let  other  task  objects  run,  MasterTask  delays  for  a  period  of  0.1 
second  before  reevaluating  a  guard. 

when  FSA_List  => 

if  el . is_parallel  then 

e2  :*=  el;  — I  Start  the  branches  together 

while  e2  /*=  NULL 

loop 

e2 .  this_event . node_task .  start  (€ 2 . this_event )  ; 
e2  :  *=  e2 .  next_e vent  ; 
end  loop; 

e2  :*=  el;  — I  Wait  for  all  of  them  to  finish. 

while  e2  /=  NULL 

loop 

e2 .  this_event .  node_ task .  stop; 
e2  e2.next  event; 
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end  loop; 

else  — I  Start  the  branches  in  sequence 

e2  :=  el; 
while  e2  /=  NULL 
loop 

e2 .  this_event . node_task .  start  (e2 .  this_event )  ; 
e2 .  this_event .  node_task .  stop; 
e2  : =  e2 . next_event ; 
end  loop; 
end  if; 

Finally,  we  have  the  cases  of  nodes  implementing  concurrent  and  sequential  actions.  The 
structure  of  these  nodes  is  the  same  except  for  a  flag  that  distinguishes  between  these  two 
cases. 

If  the  node  implements  a  list  of  concurrent  actions,  it  first  loops  issuing  calls  to  the  “Start" 
entry  of  all  of  its  children.  Since  only  the  "Start"  entry  is  called,  the  parent  does  not  block  for 
long  and  loops  back  immediately  to  start  the  next  child.  After  starting  all  of  its  children,  the 
parent  executes  a  similar  loop,  but  this  time  calling  the  “Stop"  entry  of  its  children.  Notice 
that  it  is  irrelevant  in  which  order  the  children  reach  the  accept  “Stop”  statement  and  ren¬ 
dezvous  with  the  parent,  since  the  parent  must  eventually  rendezvous  with  all  its  children. 

If  the  node  implements  a  list  of  sequential  actions,  the  behavior  is  very  similar  to  the  imple¬ 
mentation  of  the  “repeat”  guard  that  we  saw  before,  except  that  instead  of  looping  over  a 
counter,  the  looping  takes  place  over  the  list  of  children  tasks. 


4.3.  The  Main  Program 

The  main  program  invokes  the  different  components  of  MasterTask,  as  described  below: 

procedure  master  is 

Root:  Tree_Node;  — |  Syntax  tree  structure 

HeaderJS t ring :  String_Type ; 

fnode:  FSA_Node;  — |  Internal  tree  structure 

begin 

Init;  — |  Call  the  Durra  initialization  procedure 

Read_Tree (User_Source_Parameter,  Root,  Header_String) ; 

— |  Read  the  Durra  syntax  tree 

fnode  :=  Parse_Timing (Ext ractJTiming (Root) ) ; 

— |  Generate  the  internal  data  structure 

fnode . node_task . start (fnode) ; 

— |  Start  the  root  task 

fnode . node_task . stop; 

— |  Wait  until  the  root  task  is  done. 


Finish; 
end  Master; 


— |  Call  the  Durra  termination  procedure 
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4.4.  Using  MasterTask  in  a  Task  Description 

To  use  MasterTask  to  emulate  an  implementation,  the  writer  of  the  task  description  must 
write  (or  modify)  the  real  task  description  to  look  like  this: 


task  task_name 

—  required 

ports  port  declarations 

—  required 

signals  signal d eclarations 

—  optional 

behavior 

—  required 

requires  Larch  predicate 

—  optional 

ensures  Larch  predicate 

—  optional 

timing  timing  expression 

—  required 

Attributes 

—  required 

implementation  =  "master"; 

—  required 

processor  =  VAX; 

—  required 

any  other  attributes  EXCEPT  "source" 

—  optional 

structure  structure  declarations 

—  optional 

end  task_name 

Except  for  the  fixed  “implementation"  and  “processor’  attributes  and  the  absence  of  the 
“source”  attribute,  any  other  components  of  the  task  description  should  be  written  as  if  the 
real  task  implementation  were  to  be  used. 

The  "implementation"  attribute  indicates  that  MasterTask  is  implemented  by  a  program, 
“master,"  stored  in  a  special  directory  as  indicated  in  Chapter  3. 

The  "processor”  attribute  indicates  that  this  program  can  only  execute  on  a  VAX  processor. 
However,  since  MasterTask  is  written  in  Ada,  it  should  te  easily  portable  to  other  machines, 
in  which  case  the  appropriate  version  of  the  attribute  should  be  used. 

Finally,  the  absence  of  a  "source"  attribute  forces  the  Durra  compiler  to  use  as  a  replace¬ 
ment  value  the  name  of  the  syntax  tree  produced  durinc  the  compilation  of  the  task  descrip¬ 
tion.  This  is  how  MasterTask  knows  what  to  do.  It  gets  the  file  name,  reads  the  syntax  tree, 
looks  for  the  timing  expression,  builds  the  appropriate  internal  structures,  and  interprets 
them. 

It  should  be  fairly  obvious  but  nevertheless  worth  menticning  that  MasterTask  has  no  way  of 
generating  “meaningful”  output  data  or  of  making  use  of  its  input  data.  As  output  data,  it 
generates  blocks  of  random  bytes  of  appropriate  length.  All  input  data  are  dropped. 


4.5.  Using  MasterTask  In  Freestanding  Mode 

Although  MasterTask  was  designed  to  help  the  developers  of  an  application  emulate  miss¬ 
ing  task  implementations,  it  is  also  convenient  to  be  able  to  “test"  a  task’s  timing  expression 
without  having  to  build  an  "application”  around  it.  MasterTask  can  be  invoked  directly  via  a 
Unix  command: 

dmaster  task_file_name 
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The  parameter,  task_file_name,  is  the  name  of  the  file  containing  the  syntax  tree  produced 
by  the  Durra  compiler.  The  file  name  has  the  form  “name.durra.TREE,”  but  the  user  only 
needs  to  specify  name  (or  name. durra)  since  the  dmaster  command  can  supply  the  missing 
extensions.  In  freestanding  mode,  queue  operations  are  not  performed,  and  instead,  their 
duration  is  emulated  by  using  a  fixed  default  delay  (0.1  seconds). 
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5.  A  Durra  Example 

This  section  contains  a  complete  example  of  a  Durra  aDplication.  As  show  in  Figure  5-1,  it 
consists  of  two  type  declarations,  three  component  task  descriptions  (and  their 
implementations),  and  the  application  description. 

The  example  illustrates  the  use  of  a  predefined  task,  broadcast,  which  is  implemented  di¬ 
rectly  by  the  scheduler.  In  this  application,  one  task  ('  taska")  sends  out  strings  of  data  to 
the  broadcast  task  which,  in  turn,  sends  them  on  to  two  other  tasks  (“taskb”  and  “taskc"). 
The  application  description  (“main")  cements  all  of  the  component  tasks  together  in  the  con¬ 
figuration  shown  in  Figure  5-2. 


5.1.  Type  Declarations  and  Type  Descriptions 

“Byte"  is  the  basic  type  (a  scalar  type  8  bits  long).  “String"  is  an  unbounded  sequence  of 
bytes. 

“Taska"  has  a  single  output  port,  “outl,"  which  produces  strings.  "Taskb"  and  "taskc"  both 
have  a  single  input  port,  "ini,"  which  consume  strings.  Not  surprisingly,  all  three  tasks  are 
implemented  by  the  program  “master."  However,  each  task  has  a  different  behavior,  speci¬ 
fied  by  its  timing  expression. 

"Taska"  executes  a  simple  loop  three  times.  In  each  pass,  it  first  computes  for  some  ran¬ 
dom  amount  of  time  between  5  and  10  seconds,  and  then  performs  an  output  operation  on 
its  output  port.  This  output  operation  produces  the  str  ng  to  be  broadcast  to  the  other  two 
user  tasks. 

"Taskb"  waits  until  it  is  30  seconds  after  process  star-time  before  executing  a  loop  three 
times,  each  time  performing  an  input  operation  on  its  i  iput  port.  This  input  operation  con¬ 
sumes  one  of  the  strings  that  were  broadcast. 

“Taskc"  starts  by  trying  to  perform  an  input  operation  on  its  input  port,  following  which  it 
computes  for  some  random  amount  of  time  between  10  and  13  seconds.  Notice  that  the 
input  operation  is  likely  to  take  some  time  to  complete  because  the  producer  (Taska)  will 
only  generate  its  first  string  after  some  delay.  The  third  step  in  Taskc  is  a  guarded  time 
expression.  The  task  waits  until  there  are  two  elements  in  its  input  queue  before  proceeding 
to  remove  in  parallel.  The  removal  operations  take  plc.ee  in  two  concurrent  paths,  each  of 
which  waits  for  some  random  amount  of  time  before  performing  the  actual  operation. 

Task  "main"  is  the  application  description.  It  specifies  the  three  tasks  that  make  up  the 
application,  plus  an  instance  of  the  predefined  task  bro  adcast.  The  structure  part  specifies 
the  interconnection  of  those  four  tasks. 
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type  byte  is  size  8; 

type  string  is  array  of  byte; 

a  --  Type  Declarations 


task  taska 
ports 

outl :  out  string; 
behavior 

timing  (repeat  3  =>  (delay[5,  10]  outl . enqueue)  ); 
attributes 

processor  =  vax; 
implementation  =  "master" ; 
end  taska; 
task  taskb 
ports 

ini:  in  string; 
behavior 

timing  (after  30  ptime  =>  (repeat  3  =>  (ini))); 
attributes 

processor  =  vax; 
implementation  =  "master"; 
end  taskb; 
task  taskc 
ports 

ini:  in  string; 
behavior 

timing  (ini. dequeue  delay  [10,13] 

(when  current__size  (ini)  =  2  => 

(  (delay  [3,5]  ini. dequeue)  || 

(delay  [1,10]  ini. dequeue)  )  )  ); 

attributes 

processor  =  vax; 
implementation  =  "master"; 
end  taskc; 


b  -  Task  Descriptions 

task  main 

structure 

process  pi:  task  taska; 

p2:  task  taskb; 
p3:  task  taskc; 
pb:  task  broadcast 

ports  ini:  in  string; 

outl,  out2:  out  string; 
end  broadcast; 

queues  qlb[10] :  pi. outl  »  pb.inl; 

qb2[10]:  pb.outl  »  p2.ini; 
qb3[10]:  pb.out2  »  p3.ini; 

end  main; 


c  -  Application  Description 

Figure  5-1 :  Durra  Type  Declarations  and  Task  Descriptions 
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After  all  of  the  above  files  are  compiled,  the  Durra  compiler  generates  a  file  with  instructions 
to  the  scheduler.  See  [3]  for  further  information  about  the  scheduler  instructions  and  a  de¬ 
scription  of  the  Unix  commands  that  invoke  the  comp  ler  and  scheduler-instruction  gener¬ 
ator.  For  this  example  application,  these  details  are  not  important. 


Figure  5-2:  Application  Structure 


5.2.  Execution  Traces 

Each  instance  of  MasterTask  produces  a  separate  trace  file  in  which  each  line  is  prefixed 
with  a  string  of  the  form  “PID=n,"  where  “n”  is  the  process  id  number  assigned  by  the 
scheduler  to  the  task  (i.e.,  instance  of  MasterTask).  A  face  of  the  execution  of  this  example 
application  is  shown  in  Figures  5-3,  5-4,  and  5-5. 

The  first  line  of  each  trace  file  displays  the  various  tine  bases  assumed  by  the  task:  the 
application  start  time  (AT),  the  process  start  time  (PT),  and  the  day  time  (DT). 

Following  the  time  bases,  each  task  displays  the  internal  data  structure  generated  during  the 
initialization  phase.  It  is  a  prettyprinted  tree  in  which  each  node  corresponds  to  a  timing 
expression  construct.  The  structure  is  displayed  for  later  identification  of  events  in  the  trace. 

The  bulk  of  the  trace  files  display  each  timing  expression  event  and  the  time  of  ocurrence  of 
the  event.  Events  include  queue  operations  "Enqueue  ’  and  "Dequeue,”  delays  (treated  as 
a  pseudo  queue  operation),  and  guard  evaluations. 

Following  the  time  stamp,  each  event  prints  some  information  about  its  operation.  "Repeat" 
guards  have  the  string  “l="  followed  by  the  current  itera  tion  number  and  the  total  number  of 
iterations.  Other  guards  are  identified  by  the  guard  type  (e.g.,  "OP_AFTER").  "Enqueue," 
"Dequeue,"  and  "Delay"  operations  generate  two  lines  of  trace.  The  first  line  (marked  with 
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the  string  indicates  the  time  at  which  the  operation  started.  The  second  line  (marked 
with  the  string  “<•")  indicates  the  time  at  which  the  operation  completed.  Depending  on  the 
event  type,  some  lines  will  make  reference  to  a  node  in  the  timing  expression  syntax  tree. 
These  are  marked  with  the  string  “N="  followed  by  an  integer,  where  the  integer  is  the  node 
number,  as  labeled  in  the  prettyprinted  tree  shown  at  the  beginning  of  the  trace  file. 
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